11.1　LeSS のプロダクトバックログリファインメント

関係のある原理原則

プロダクト全体思考

個々のチームがそれぞれ異なるアイテムのリファインメントを行う（部分最適）と、ドメイン知識が制限され、アジリティが減り、調整が難しくなる。これに対処する方法が重要。

顧客中心

従来型の組織では要求はサイロ化されたグループの技術的・機能的タスクであることが多く、顧客の真の目標ではない

LeSS 導入段階で起こりうる事

多くの開発者が顧客の要求全体、顧客の話す言葉、ドメイン知識に詳しくない

多くの開発者が問題解決のために顧客と一緒に作業することに不慣れである

リーン思考と待ち行列理論

古い組織ではいくつかの機能グループ（e.g. プロダクトマネージャー, UI デザイナーなど）が要件の理解と定義に関わり受け渡しを行う。

その結果、無駄と中間の成果物として仕掛り中のドキュメントのキューがたくさん生まれる

局所的には効率的に見えるが、真のコストや問題が把握しづらい状況になる

LeSS のルール

code:LeSS のルール

プロダクトバックログリファインメントは、将来そのチームが対応しそうなアイテムについてチームごとに行われます。複数チームや全体で PBR を行うのは、関連性が強いアイテムがあったりより広範なインプットと学び得る必要があるときに、共通理解を深め、互いに関連した PBI について協力する方法を探ったりするためです。

プロダクトオーナーだけでプロダクトバックログリファインメントをするべきではありません。複数チームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダクトオーナーをサポートします。

すべての優先順位付けはプロダクトオーナーに確認をとりますが、要求や私用の詳細確認は極力チーム間や顧客、ユーザーまたはステークホルダーと直接行います。